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ADS LR AGE 


This paper presents a study of the problem of systen 
deadlock with emphasis on the allocation of serially 
reusable resources. The initial area of concentration is on 
a definition of system deadlock and a presentation cf proven 
methods cf handling deadlock. After the discussion of 
current theory, two major operating systems are examined. 
An overall description of the functioning of 05/7360 is 
presented followed by a detailed discussion of the 
procedures used by 05/360 to allocate serially reusable 
resources. The Michigan Terminal System is then discussed, 
outlining the techniques of resource allocation employed. 
The paper is concludeä by correlating the methods used in 


05/3609 with those of MTS. 
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Ts INTRODUCTION 


ad 


in the present age of the computer there is an ever 
increasing demand for computer power. To some extent this 
demand has beer fuifilled by using bigger and faster 
computers, but economic constraints have dictated that 
computers must aiso be efficient. The efficient utilization 


of computers is often achieved through multiprogramming. 


In a multiprogramming environment several processes are 
active concurrently; ccnseguently, there is NCW an 
interaction between processes as they compete for system 
resources. When Several processes compete for resources it 
is possille that more than one process will require a given 
resource at some point in tine. In this situaticn one 
process will be given control of the resource in question, 
and all cther processes will be blocked until the resource 
again becornes available. If two or more processes are 
mutually blocking each other from further execution the 


situation is known ace deaddsock. 


An investigation of the problem of system deadlock is 
undertaken in this thesis. A study of available literature 
on deadlock was conducted to determine what has been done in 
this area. An attenpt is made to consolidate this 
information into a unified presentation of current theory. 
A second objective was to closely examine two major 
operating systems to determine which deadlock strategies 
have been employed in each and what methcds were used in 
their implementation. The two operating systems selected 
for this study were IBM's 05/360 and the University of 
Michigan's Michigan Terminal System (MTS). 





TI. WenERENT THEORY 


RS + un A un m e eee 


In studying the current literature on the subject of 
System deadlock it is evident that there are a limited 
number cf authors in this area. It also appears that these 
authors are very much in agreement on the basic facts. The 
variance 1s encountered in nomenclature and representation 
methods. While one author [Habermann 1969] prefers a vector 
notation and uses matrix manipulation to define deadlock, 
another [Holt 1971] [Holt 19721] prefers a graphic 


representation and defines deadlock accordingly. 


As a result of reading much of the current literature 
the authcr has developed a view of the deadlock problem 
Which includes points presented by several writers. The 


following is a presentation of that view. 
A. DEADLOCK DEFINITION 


A simple instance of deadlcck occurs when two processes, 
P1 and P2, use two common resources, R1 and R2. Assume that 
each process requests resources as they are needed and 
further assume that a resource cannot be released by a 
process Which 1S waiting for a requested resource. Suppose 
process P1 has resource R17 allocated to it and requests R2; 
process F2 haS resource R2 allocated to it and requests Rl. 
This is a deadlock situation because by requesting the same 
two resources in reverse order each process has made a 


request which cannot be satisfied. 


The simple case of system deadlock has been extended to 
include any number of processes and resources [Holt 1971] 


{Holt 1992]. Holt has presented a number of theorems which 





define necessary and suffacient» conditions wfore deadloeik 
For a complete description based on graph theory methcds the 
reader shculd refer to [Holt 1971). In general terms, 
Geadvock will occur in any situation in which there is a 
closed locp of processes each requesting a resource (s) 


allocated to another process within the loop. 


Although deadlock can occur from any type of process 
interaction, we shali emphasize the allocation of serially 
reusable resources since most system resources are serially 
reusable [Havender 1968]. Some examples are: storage 


media, system components, and information. 


Storage media (such aS main memory, tape, and disk or 
drum tracks) are considered to be serially reusable because 
they contain only one set of information at a time. When 
that set cf information is no longer needed, the media can 


be used again to hold a new set of information. 


System components (such as tape drives, disk drives, 
central processing units, and access mechanisms) are 
serially reusable because they are generally dedicated 
totally to cne process at a time. One might argue that a 
disk drive may have a disk containing information for many 
processes and should therefore be considered shareable. 
This-is true, but if the volume contains cnly infcroxation 
for one specific application it can be considered serially 


reusable. 


Infortation is intrinsically shareable, unless it is 
defined as nct shareable for security reasons. Information 
beccmes serially reusable when it is being changed. When 
one process is updating a record, no other process can 
access that record until the update has been completed. 


This particular problem has been termed the "critical 





Section" probken sand has» been the subject of its own 


solutions {Dijkstra 1965 ]. 


Serially reusable resources can be characterized ty the 
following five properties [Coffman 1971] [Holt 1971] (Holt 
2972]. 


(1) There is a fixed number cf units of each resource. 
When all of the units of a given resource have been 


allocated no further requests can be fulfilled. 


(2) Each unit of a resource is either assigned to a 


particular process or is available for assignment. 


(3) A unit of a resource can be allocated to at mcst one 


process at a tine. 


(4) A process can release any resource which it has 


acquired but not yet released. 


(5) A resource assigned to a process can not be 
pre-empted by another process. Once a resource has been 
acquired it does not become available until it is 


released by the process which holds it. 
B, DEADLOCK STRATEGIES 


Any system in which processes compete for resources must 
have a strategy for handling the deadlock problem. These 
deadlock strategies pelong tc one of three classes: 


prevention, detection, or crash [Holt 1971] [Holt 1972). 
1. Prevention 


Under deadlock prevention the system is designed in 
Such a way that deadlock is not possible. As would be 
expected, prevention algorithms tend to be overly 


restrictive. In many cases a process! request for resources 





is not granted even though such action wouid not lead to 
deadlock. 


The Simplest prevention algorithm is tc allow 
execution of but one process at a tine. This method 
certainly prevents system deadlock, but it aiso prevents 


multiprogranmring. 


A second means of deadlock prevention requires 
collective requests for resources. A process must acquire 
all the resources it will use before it begins to ezecute. 
In this case a running process can never be blocked Ey an 
outstanding request for resources. AS each process 
terminates it releases its resources and thereby insures 
that a blocked process will eventually acquire its 
resources. The obvious disadvantage of coliective requests 
is that many resources may be allocated long before they are 


used, therehy denying their use by other processes. 


A third method of deadlock prevention makes it 
possible to avoid allccating resources long before they are 
used. Under this method a process holding fcrmerlv ottained 
resources must release those resources before reguesting an 
additional resource. If any of the original resources are 
still required they must be re-requested along witn the 


additional resource [ Havender 19601: 


A more complicated method is known as crdered 
resources [ Havender 1968) [Holt 1971] [Holt 719775 
ResourceS are partitioned into k classes, numbered 
IZ y... ¿E A process is allcwed to request resources in 
class i only if it has not already been allocated resources 
in classes i, itl, ..., k. Deadlock is prevented because 
two processes cannot request the same resources in different 
order as described in the initial example. Any process 


which holds a class k resource cannot be blocked and will 





eventually release its resources. Consequently, any process 
holding class k-1 resources (and can only request class k 
resources) wiil receive its requested units and can rrocede 
to terminaticn. This reasoning can be extended to verify 
that any process hoiding resources of any class wili 
eventuaily receive ail of its requested units and therefore 


Will never reach a deadlock situation. 


Using ordered resources, the more valuable a 
resource is, the higher its class should ke. Resources in 
class k can ke requested when actually needed and released 
as soon as they are not needed. Thus the higher the class 


Of a resource the more efficiently it is used. 


2. Detection 

As the name implies, this strategy allows deadlocks 
to occur and takes corrective action when a deadicck is 
detected. Deadlock detection algorithms have been presented 
which examine the status of the system at any given instant 
to determine when corrective measures are required [Coffman 
1971] (Holt 1971) [Holt 1972]. Once a deadlock has been 
detected the system can recover by terminating the 
deadlocked processes or by pre-enpting resources fron 
processes. Usually it is not necessary to terminate all of 
the . deadlocked processes to recover. AS soon as one of the 
processes acquires enough resources to begin executicn the 


deadlock has been broken. 


The obvious question which arises is which process 
is to be the one terminated or to have its rescurces 
pre-empted? It would be desirable to chose the process with 
the lowest associated cost. This cost could be defined as 
the cost cf restarting the job and running it again to the 
point of termination or pre-emption. The difficulty 


enccuntered is determining this cost. It is not enough to 





simply consider the amount of computer time used Ly the 
process up to this point, but one must also consider the 
integrity of the data invoived. it is possible that 
terminating a process may result in a major effort to 


restore the data base to its original form. 


Another method of determining restart cost would be 
to break down all processes into classes, each with an 
arbitrarily assigned cost. For example, in an academic 
environment the classes might be: Student jobs, staff 
research jobs, and system jobs. In this case the students 


processing wouid be the first terminated or pre-empted. 


This strategy can allow higher resource utilization 
than is possible when deadlock is entirely prevented. It is 
the preferred method in those systems where deaälcck is 


infrequent and the cost of recovery is not prohibitive. 


Under this strategy deadlocks are neither prevented 
nor detected by the operating systen. Te is the 
responsibility of the computer operator to determine when a 
deadlock has occurred and to take appropriate steps to 
remove it. The only possible advantage of this strategy is 
that-it saves the time and Space required by the prevention 


emda detection routines. 
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III. OPERATING SYSTEM/360 


The presentation on IBM's Operating System/360 (CS/360) 
is based primarily on information obtained from IBM frogran 
logic manuals. These manuals deal with the operating system 
functions at avery detailed level and hence were adequate 
for the purposes of this paper. The primary drawback of 
these manuals is that they are replete with abbreviations 


and conseguently are difficult to comprehend. 


The discussion on deadlock prevention in OS/360, as it 
pertains to serially reusable resources, is essentially a 
discussion» of job initiation. It sas during the initiation 
of a job step that all serially reusable resources are 
eeerocated, and thus where the deadlock prevention algorithms” 
are encountered. Before a detailed description of the 
initiatcr is given, it is appropriate to briefly describe 
the general structure and functions of 0S/360. 


A. GENEKAL ORGANIZATION > 


The operating system is divided intc three major 
functional areas: job management, task management, and data 
management.. 


The primary functions of job management are: analysis 
of the job stream, overall scheduling, allocation of 
input/output devices, and direction of setup activities 
[Witt 1966 ]. The functions Of job | management are 


accomplished by the master scheduler and the job scheduler. 


The master scheduler serves as a communication control 


link between the operator and the system. It processes 
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commands from the operator to the operating system and 


outputs messages from the system to the console typewriter. 


The jcb scheduler consists of three primary elements: 
the reader/interpreter, the initiator/terminator, and the 
system writer. The reader/interpreter reads the input 
stream, converts the control statements into tabular forn 
and places them into the job input queue. The initiator 
selects the highest priority job from the input gueue, 
oktains a region of main storage, collects the reguired data 
sets, allocates I/O devices, and turns the job step over to 
task management. Upon completion of execution, the 
terminator directs the disposition of data sets and releases 
the I/O devices for allocation to other tasks. The system 
writer takes the output data sets produced by the jok step 
from the cutput queue and puts then to the appropriate 


Output device. 


Task management controls the job step during its 
execution. Ihe functions of task management consist of the 
fetching of required load modules; the dynamic allocation of 
CPU, storage space, channels, and control units on behalf of 
competing tasks; the services of the interval timer; and the 


amen rOonization of related tasks [Witt 1966]. 


The data management programs are primarily responsible 
for moving information between main storage and external 
storage and maintaining it in external storage. This is 
achieved by maintaining the system catalogue, previding 
various access methods and buffering techniques, processing 
volume labels, and protecting data via passwords [Clark 
1966). 


The above description of 0S/360 was intended only to 
provide a basic view of the environment surrounding the 


system mcdules to be discussed later. For a more complete 
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Hescripticnthe reader should, consult the ahomes cisked 
references and/or the IBM Manual, Cperating System 


Introduction [IBM 1971]. 
B. RESOURCE ALLOCATION 


The discussion on resource allocation is presented on 
two different levels. The first level is general in nature 
and covers key points involving resource allocation and 
deadlock prevention. The second level appears as Appendix C 
and gives a detailed module by module description of the 
actions of the initiator. To aid those readers not familiar 
with IBN systems, Appendix A contains a glossary cf IBM 
terms and Appendix B contains a descripticn of relevant IEM 


system macro instructions. 


The basic mechanism for controlling a resource is a fair 
of macro instructions, ENQ and DEQ. ENQ requests the use of 
a resource and specifies whether the ccntrol is to be 
exclusive or shared. DEQ is used to free resources oktained 
by the use of an END. 


The initiator is used to start both system tasks and job 
step tasks. To initiate a task the initiator retrieves job 
control information about the task and reserves systen 
resources for the use of the task. After resource 
allocations. are completed, the initiator passes contrcl to 
the task. On task completion, the termination routine of 
the initiator releases all of the task's system rescurces. 
The acticns cf the initiator during the initiation of a 


typical job are discussed below. 
1. Job Selection 


Ihe first function of the initiator is to select a 


job from the input queue containing jobs arranged by 





Prior within" jòb class. Tado this, the iniWatcr uses 
the ENQ macro to obtain exclusive control of the queue 
control record. Once the initiator gains Control of the 
queue ccntrcl record, it examines it to determine if there 
are any jobs in the queue of the class serviced ty this 
Particular initiator. If so, the highest priority job 
within the class is selected. The initiatcr then issues a 
DEQ which permits access to the queue control record by 


other routines. 


The initiator then determines how many steps are in 
the job and what data sets will be required. Next it 
prepares a parameter list for the ENQ macrc specifying each 


Mata set name and whether its use is exclusive or Shareable. 


2. Regicn Management 

The initiator then determines the amount of main 
storage required by the job step and issues the ENQ for its 
data sets. If all of the data sets cannot be obtained, the 
initiator issues a DEQ to free those which were obtained. 
This prevents possible deadlock between jobs with 
overlapping data set requirements. At this pcint the 
Operator is given the option of retrying the ENQ, cancelling 


the job, or waiting for the data sets to become available. 


When all data sets have been secured, the initiator 
then reguests the region of main storage. When the region 


has been obtained, device allocation begins. 
3, 1/0 Device Allocation 
The operating system contains a table cf unit 
control preeks. Each unit control block contains all of the 


infcrmaticn about a specific device that the initiatcr needs 


to make device allocations. In order to prevent multiple 
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ses to the unit control blocks during allocation, the 
ator uses the ENQ to get exclusive control of then. 
INQ nct only prevents Simultaneous allocation of devices 


sore than one job step, but also prevents the terminator 


freeing any devices. 


If allocation cannot be completed because of lack of 
es, the operator is given the option of cancelling the 
| making a device available which is offline, or waiting 
Jevices to become available. Tf tie "Walt. opticn is 
cted, the unit control blocks are DEQ'ed and the 
iator waits until another task terminates, thereby 


ing its devices. Allocation is then attempted again. 


When all devices have been allocated the initiator 
es a DEC on the unit control blocks and the job stef 1s 


Ma fcr execution. 


IN Task Tecmination 


Sa me ao es Ma es ee ee ee ee eee eee D rad 


When a task reaches normal completion or abnormally 
execution, it is handled by the terminator, which acts 
ı sukreutine of the initiator. The terminator performs 
‘required data set disposition and frees the I/O devices. 
free the devices the terminator must use the ENQ to gain 
lusive ccntrol over the unit control blocks. After all 
ices have been freed, the terminator then issues a DEQ to 


E. the unit control blocks. The initiator is now free 


| 


process the next job step. 


| 
| SUMMARY 

The atove study of 05/360 has revealed quite cleariy 
t deadlock strategies have been incorporated into this 


rating system. The designers of this system have chcsen 


prevent deadlock rather than to let it occur and then 
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take corrective action. It was probably their conclusion 
that, under the vast range of computing environments in 
which 0S/36Q is used, preventing deadlock was more practical 
than implementing detection algorithms. 


The methcd of deadlock prevention used in 05/360 is a 
comkinaticn of two methods discussed at the beginning of 
this paper. The two methods are known as collective 
resources and ordered resources. The method of collective 
resources is applicable because à task must obtain all the 
resources it will use before it begins to execute. The 
method of ordered resources comes into play in that all 
resources are divided into three classes: data sets, main 
storage, and 1/0 devices. During allocation main storage is 
nct requested until all data sets have been acquired; I/O 
devices are not requested until all data sets and main 
storaga have been obtained. 
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It was planned that this section of the thesis would 
contain a study of the Michigan Terminal System (MTS) 
comparable tc that presented for 0S/360. This study vas to 
be carried out in connection with the implementation of MTS 
on the Naval Postgraduate School computer. However, MIS was 
undergoing revision at the Yniversity of Michigan and delays 


in its distribution precluded such a study. 


In the absence of the current release of MTS and its 
associated documentation a much more limited effort was 
conducted. fhe primary sources of information were the 
computing center newsletter and memos published by the 
University of Michigan, various articles written by the 
designers of MTS, an assembly listing of a prior version of 
MIS, and telephone contact with the staff at the University 
of Michigan. 


A. GENERAL ORGANIZATION 


MTS is an operating system which offers both batch job 
and © terminal usage. It was designed to take advantage of 
the special relocation hardware and multiple central 
processors offered by the IBM 360 model 67. In crder to 
facilitate extension and modification, the system is 
Organized as a set of independent components with well 
defined interfaces. “he four primary components are the 
University of Michigan Multi-Programming Supervisor (UMMPS), 
the Paging Drum Processor (PDP), the Michigan Terminal 
Systen (MTS), and a highly modified version of the Houston 
Automatic Spcoling Priority system (HASP). 
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UMMPS is a set of subroutines which run in privileged 
state with interrupts disabled. All entries to the 
supervisor are made through interrupts and are processed to 
completion before giving up the processor [Alexander 1971]. 
It processes all interrupts; does all physical input/output; 
allocates and schedules devices, main storage, and CPU's; 
and provides inter-task communication and protection 
[Ecettner 1970] [Alexander 1971]. 


The PDP runs under the control of the supervisor and is 
responsible for maintaining external page storage and for 
moving pages between main storage and auxiliary storage 
{ Boettner 1970] [Alexander 1971]. The auxiliary storage 
used is cne or more drums or disks; these devices are under 
the complete control of the PDP. 


MTS is a re-entrant program which is activated once for 
each terminal in the system and once for each running batch 
job [Boettner 1970}. In effect each user in the system has 
his own private copy of MTS. It provides device support 
routines, performs file handling functions, does ccmmand 
processing, and interfaces input/output with HASP. 

HASP is a non re-entrant program which controls the card 
readers, punches, and printers on the system and maintains 
the ` input/output spool queue. The modifications to HASP 
have transformed it into a batch monitor. As such it 
generates MTS batch tasks and starts them executing. The 
numker of katch jobs executing at any one time depends upon 
the system load [ Boettner 1970]. 


B. RESOUFCE ALLOCATION 
Our discussion of allocation under MTS will be based on 


the type cf resource being allocated, specifically, main 


Storage, files, and I/O devices. 
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The task of moving pages between main storage and 
auxiliary stcrage is shared by UMMPS and the PDP. UMMPS 
determines which pages are to be read into memory or written 
out to drum and the PDP does the reading or writing. 
Communication between UMMPS and the PDP is accomplished by 
placing a Page Control Block (PCB) on one ci four queues: 
the Page In Queue (PIQ), the Page In Complete Queue (FICQ), 
the Page Cut Cueue (POQ), Or tne Release Page Queue (RPQ) 
[Alexander 1971]. An explanation of these queues and the 


PCB iS contained in Appendix D. 


The EDP utilizes five supervisor calls in its normal 
operation. These supervisor calls, described in Appendix E, 
are: Get Real Page (GETRP), Free Real Page (FREERE), Get 
Write Page (GETWP), PDP Wait (PDPWAIT), and Get Çueues 
(GEIOS) [Alexander 1971]. 


When the supervisor determines that a page must be 
read into main storage it will place the PCB for that page 
on the PIC. Likewise, the supervisor will place pages which 
have been released by tneir tasks on the RPC and pages which 
could be removed if necessary on the POQ. After placing a 
page on the PIO the supervisor will start the PDP, if it is 
idle. 


The PDP will call the GETOS subroutine which will 
return all PCB's on the PIQ and the RPQ. It next calls 
GETRP to obtain a main storage block to read each page into. 
In the event that no block is available, the GETWP routine 
will return pages to be written and main storage will kecome 
available. 
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When the PDP has obtained a block for each page to 
be read in, it constructs a channel program which will read 
the required pages into main storage. The channel program 
is generally constructed to accommodate nine pages at a 
time. Tf all nine siots are not filled Ly read requests, 
the PDP will call GETWP to attempt to get enough pages to 


il the unused slots with writes. 


When the channel program has been constructed for 
all the reads and writes, it will be queued for execution. 
During executicn of the channel program, a program 
controlled interrupt is generated as each page transfer is 
completed. These interrupts are not queued and are lost if 
not serviced imnedjately. At the end of the channel 
program, however, an interrupt occurs which is queued. 
Interrupts of either type signal the PDP. The ELE then 
places the PCB's for pages read on the PICC and calls FkEERP 
to release the main storage blocks for all pages written. 
The supervisor will detect the pages on the PICQ the next 
time it is entered and will restart the tasks waiting for 
then. 


The PDP also has the ability to detect unnecessary 
Meecs and writes and elininate then. For example, if a page 
has «not been changed since it was last read in, there is no 
need to write it back out again. By the sane reasoning, if 
a page is requested again before it has keen freed Ly the 


PIP, the copy already in main storage can be used. 


RE SS a wee ae 


MIS supports the concept of shared files. After a 
user creates a file he has the ability to specify which 
other users may have access to this file and what type of 


access they may have. The owner of the file can lirit the 
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access to himself, to other users by individual user 
identificaticn numbers, to other users by project number, to 
all other users, or to any combination of the above [U of 
Bach 19720]. AS the owner of the file specifies who has 
access he also defines the extent of the access. The 
varicus degrees of access to a file are: the ability to 
read from, the ability to add to but not change existing 
infcrmation in the file, the ability to change or delete but 
not add tc, the ability to truncate or renumber, the akility 
to destroy or rename, the ability to modify the right of 


access, or a combination of the above [U of Mich 1972t]. 


The system controls the concurrent use of shared 
files by maintaining a system wide shared file table. This 
tatle contains an entry for each file currently in use which 
describes how and ty whom each file is being used. The 
system also requires that a file must kte locked in the 
appropriate manner before any operation can be performed on 
that file [U of Mich 1972a]. 


MIS provides three level of locking. The lowest 
level is lccking a file for reading. The second level is 
locking a file for modification, which includes adding, 
changing, deleting, truncating and renumbering. The highest 
MWEN of locking a file is for destroying; this includes 
renaming and changing the rights of access. At each level 
of locking the user also has the file lccked for the 
oferations allowed by any lower level cf locking [U cf Mich 
197Zza]. As is normally true, any number of users may have a 
file locked for reading, but when a user has a file locked 
for modification or for destroying he must have exclusive 


use. 
When a user requests a file, MTS determines whether 


or not he has been granted access by the cwner of the file 


and, if so, has he been granted the degree of access 
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reguested. Ir the answer to the two akcve questicns is 
afirmative, MIS then consults the shared file table to 
determine if the required level of liccking can te made 
without violating the rules requiring exclusive control. If 


so the file is locked as requested. 


If another task already has the file locked and the 
current request cannot be honored, MTS will enqueue the task 
on the file and put it in a wait until the file can be 
locked. Before engueueing the task, MTS will ensure that 
placing the task on the queue will not result in a deadlock 
situation. Perhaps this can best be illustrated through the 


use of an example. 


Ccnsider a situation similar to the one presented on 
page five. Assume that task Ti has file Fi locked for 
reading and that task T2 has file F2 locked for reading. 
Now suppose task T1 requires file F2 to ke locked for 
modification. MTS will determine that F2 is locked for 
reading and will queue Ti to wait until T2 has completed its 


use of FZ. 


If at this point T2 now has a reguirement to modify 
F1, MTS will determine that putting T2 cn a queue tc wait 
for file F1 would result in deadlock. Therefore, it will 
not -place task T2 on the queue, but will instead indicate 


feat an errcr condition exists. 


What happens as a result of the error condition 
depends upon the type of job involved. If T2 is a batch 
job, it will ke terminated, releasing all of its resources. 
It will then be returned to the HASP input queue in a hold 
Status tc be released by the operator to rerun at a later 
time. If T2 is a terminal job, an error message will be 
sent to the user indicating the deadlock situation and he 


must decide what corrective action is to be taken. 


ZAN. 





Be. IZO Deviees 


MIS in general divides its I/O devices into two 
classes. Cne class consists of unit record devices such as 
the card readers, punches, and printers; the other class 


eon ists of all other devices. 


The unit record devices are contrclled by HASP. 
When a task requires a unit record device it is assigned a 
pseudo-device. As the task reads from or writes tc this 
pseudo-device it is actually reading from or writing to the 
HASE spool queue. HASP in turn performs the I/O operation 
to a physical device as devices become available, assigning 


the tasks on a priority basis. 


Cther devices can be allocated either befcre the 
task Legins executicn or during the execution of the task. 
The time allocation takes place is determined by the method 
employed ky the user in requesting the device. If the user 
prefers that allocation take place before execution begins, 
he must use a system command which invokes the MOUNT 
program. If allccation is to take place as needed during 


execution, the MOUNT program is called as a subroutine. 


In either case the MOUNT progranm is supplied with 
the type cf device required and the name of the file to 
mounted on the device. The MOUNT routine issues a message 
to the ccnsole operator requesting a device by type and 
indicating the volume to be placed on that device. If the 
Operator can determine that there are not enough devices 
available to satisfy the allocation request, he can at this 
time so indicate. By doing so he forces a Latch jok to be 
returned to the HASP input queue, or forces a terminal user 


to decide on an alternate course of action. 
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If devices are available, the operator responds with 
a specific device address. The MOUNT routine then issues an 
SVC to enter the UMMPS allocaticn routine which attenpts to 
allocate the naned device. If the device is available, it 


is allocated and the operator is given confirmation. 


In the event that the device named by the operator 
has already been aliocated, is inoperable, or has been 
varied offline, an error condition is indicated. The 
response to this error condition is the, same as that 


previously described for files. 
Se SUMMARY 


The akove study of MTS does not reveal a clearly defined 
deadlock strategy. The allocation method encountered is 
different for each type of resource involved and there does 
not appear to be any interrelationship between then. 
Consequently, the deadiock strategy is at best difficult to 
PinpEoint. 


Of the three deadlock strategies described in the early 
part of this paper, prevention is the most appropriate to be 
associated with MTS. However, MTS does not employ any of 
the methcds of prevention previously discussed. In spite of 
this.fact, there is evidence supporting the choice of 


deadlock prevention as the strategy incorporated by MTS. 


The most convincing evidence is displayed by the lccking 
technique used in the control of files. Eefore a task is 
gueved on a file, the system checks to see if such queueing 
would result in deadlock. If sc, the task is not queued and 


deadlock is prevented. 


A mcre suktle prevention technique is encountered in the 


ailccaticn of main storage. Paging of main storage ensures 
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that no task will be blocked permanently from execution 
because it cannot get memory space. If a task has memory 
Space and is blocked while waiting for another resource, its 
pages will gradually migrate to auxiliary storage enabling 


other tasks to get space. 


The deadlock prevention method used in the allocation of 
devices is less sophisticated than that used for main 
storage or files. In fact it can be considered as no method 
at all. The issue is avoided by forcing tasks which cannot 
aliocate devices to be rerun at a later time, in the hope 


that allocation will be possible when rerun is attempted. 
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Va CONCLUSTONS 


ee ee ee OR A a a 


Studying the resource allocation techniques of CS/360 
and MTS has revealed strengths and weaknesses in both 
systems. Possibly at some time in the future an operating 
system will be developed which incorporates the good 


features and eliminates the poor features of both systems. 


An advantage of 05/360 over MTS is that OS does not 
require interaction with the operator during the normal 
allccaticn cf devices. In a production environment where a 
majority of the I/O is not of the unit reccrd type, much 
time would be lost waiting for the operator to choose a 


device and type in his response. 


Both systems use undesireable methods when the 
allccaticn of all requested resources is not possibie at the 
time of the request. Under OS the operator is given an 
option which includes cancelling the job or waiting for 
resources. If he chocses to cancel the job, it is flushed 
out of the systen. why? Since OS requires coliective 
allocaticn of resources, the task has not yet kegun to 
execute. It wculd seen logical to place the job back on the 
input queue. and attempt to run it later. If the opetator is 
reluctant to cancel the jon and puts it into a wait the 
initiator is tied up during this period and cannct begin 
another jcb step. This is especially dangerous when the 
Operator kas no idea how long this wait may be. If he is 
not careful he may seriously degrade the performance of the 
systen. For example, this could happen if he put mcre than 
one job into a wait when the resource required was being 


held by a job which will run for several hours. 
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Under MTS the situation is different. When a task is 
put into a wait condition it does not hamper the execution 
of the reraining tasks and will not prevent other tasks from 
beginning to execute. The drawback comes when a task is 
terminated and returned to the input queue. Since MTS 
allows allocation of resources at any time, it 1S fcssible 
that a major file modification could have been in  prcgress 
or completed at the time the job was requeyed. Arbitrarily 
rerunning such a job can cause serious file integrity 
protlens. It becomes the user's responsibility to avoid 


rerun under this type of condition. 


In the argas of memorv and file management, MTS utilizes 
the most effective techniques. Under OS a task requires a 
contiguous area of main storage to execute. The rapid 
reallocation of memory that occurs during multiprogramming 
tends to fragment the available memory Space. Cften a 
region cannot be allocated, even though enough free space 
exists, kecause this space is not contiguous. The paging 
method of MTS alleviates two problens: first, the entire 
task does not have to be in main storage at one time, and 
seccnd, the portion of the task which is in main storage 


dces not require a contiguous area. 


Under OS the only files which can be used concurrently 
are direct access files. If a user wishes to share a disk 
file with cthers he has no way of restricting it to specific 
users and, even then, his restriction is only in effect 
during the time that the file is allocated to him. MIS not 
only gives the owner of a file the ability to share it with 
other users, but also the ability to restrict the tyje of 
access granted to each. Also, these restrictions are 
persanently associated with the file and are not in effect 
just while the owner has the file allocated to one of his 


tasks. 
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As far as system deadlock is concerned, it appears that 
both systens prevent deadlock but the metnods used can at 
times be very costly. Unfortunately it is much simpler to 
point out the shortcomings of either system than to present 


an alternative soluticn. 
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APPENDIX A 


This appendix contains explanations of IBM terms used 


in discussing resource allocation in 0S/360. 


Allccate Work Table: The Allocate Work Table is constructed 
by a submodule of the I/O Device Allocation 
routine. The table contains an entry for each DD 
Statement in the input stream. Each entry contains 
information which describes the data set and 
information that is used in allccating a device to 
ite This information includes the number of 
volumes in the data set, the number of dévices 
reguested, the number of devices allocated, the 
numker of devices shared, the DD number, the number 
cf devices available for allocation, and a bit 
pattern representing which devices are eligible for 


allccation. 


Job Control Table: The Job Control Table is created ty the 
interpreter and placed in the input queue. It 
contains information from the JOB statement, job 
status er and pointers to other takles in 
the job!s input queue entry. It also contains the 
job region size, number of Step Input/Cutput 
Tables, and whether the job is to have 
checkpoint/restart [IBM 1972a ]. 


Link Pack Area: The Link Pack Area 15 a region at the top 
(highest addresses) of main Storage. This area 
contains useful re-entrant routines and tables 
which remain core resident. These routines and 


tables are generally highly used and having them 
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core resident eliminates the time required to read 
them in from disk or drum. Which routines are to 
be included in the Link Pack Area is determined 


before the system is generated [Flores 1973]. 


Queue Control Record: The Queue Control Record is made up 
CÉ a series of pointers to entries ın the queen 
Gne entry points to the highest pricrity jok in the 
queue. The remaining 15 entries point to the last 
job entered into the queue for each priority. (The 
elements within the queue are chained from highest 
to lowest priority, with jobs within a [riomity 
arranged in order of entry.) The organization of 
the Queue Control Record facilitates removing the 
highest priority job from the queue or entering 
jobs to the end of each priority string [IBM 
1972320: 


Steg Control Table: The interpreter constructs a Step 
Control Table for each step of a job. This table 
describes the job step and is utilized by the 
initiator in making allocations. It contains the 
step name, program name, maximum step running tire, 
nunker of Step InputyOutput Tables, step completion 
code, pointers to the first Step Input/Output Table 
and the next Step Ccntrol Tabie, and other pointers 
and status information [IEM 1972a]. 


Step Input/Output Table: The interpreter creates a Step 
InputyOutput Table for each DD statement in the 
input stream. This table completely describes the 
data set, its I/O device requirements, and contains 
a pointer to the next Step InputyOutput Ttatle for 
the step. The information contained in the table 
is used by the initiator to build the Task 
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Input/Output Table and is used by the Allocation 


and Disposition routines [IBM 1972a]. 


Supervisor Çueue Space: The Supervisor Queue Space is a 
region of main storage just above the Nucleus. It 
contains control blocks, lists, and tables reguired 
by the control program. The maximum size of this 
area is specitied at system generation time and 
space is allocated and freed from within this area 


as required during execution [Flores 1973]. 


Task Input/Output Table: The Task Input/Cutput Tatle is 
contructed by job management routines. It resides 
in main storage during step execution and provides 
information to various 1/0 routines. The table 
contains the job name and step name. It also 
contains an entry for each data set reguested for 
the step. This entry contains such information as 
label processing insructions, rewind and unlcading 
instructions, unit affinity or channel separation 
requirements, and volume mounting instructicns [IBN 
197p: 


Unit Control Block: There is a Unit Control Block for each 
device on the systen. It contains infcrration 
describing the device characteristics, the current 
device status, the internal job identificaticn, the 
protection key of the job, the serial number of the 
volume assigned to the device, label information, a 
pointer to the device error routine, and other 
information required by to the I/O supervisor and 
vor scheduler. ach Unie Control Bock! Meontamns 
two segments, a segment containing inforration 
ccmmon to ali devices and a segment containing 


device peculiar information {IBM 1972b}. 


31 





APPENDIX B 


The macrcs described below can each be thought of as an 
interface to a system routine. When the Assenbler 
emeounters che of these macros it generates a series of 
instructions to pass parameters aná originate a supervisor 
call (SVC). At executior time the SVC instruction causes an 
interrupt. The SVC interrupt handler determines the type of 


SVC and reutes control to the appropriate system rcutine. 


ATTACH: The ATTACH macro causes the control program to 
create a new task and indicates the entry point in the 
program. The new task 1s a subtask of the task which 
issued the ATTACH macro and it assumes the dispatching 
priority of the originating task. The issuing [rogram 
Can prcvide the attached task with a parameter list, 
an exit routine to be given contrcl when the task 
terminates, and a control block in which to post its 
termination. If a usable copy of the progran tc be 
given control is not in main storage, it is loaded 
LEBMI2372c ]. 


DEQ: The DEQ macro causes the control program to remove 

| control of one or more serially reusable resources 
from the issuing task. The DEQ macro must be used to 
release every resource obtained through the use of the 
ENC macro. If a task attempts normal termination 
while it still has control of any resources assigned 
through an ENQ, it will be abnormally terminated [IBM 
7 2C jis 


ENQ: The ENQ macro requests that the control program 


symbolically assign control of one cr more serially 


32 





reusable resources to the task issuing the macro. 
ACCESS to a resource is logically, not physically 
restricted. This means that a task may use a serially 
reusable resource without using the ENQ macro, but 
results of doing so may te unreliable. Once ccntrol 
Of à resource is symbolically obtained by a task, it 
remains until that task issues a DEQ macro specifying 


the same resource [IBU 197207 


FREEMAIN: The FREEMAIN macro asks the control program to 
free space that is no longer needed. The space which 
can be freed 1S any space obtained through the use of 
the GETMAIN macro. The space is freed by adding queue 
elenents representing the space to chains recording 
free “areas of main storage. ff the area to DEEE 
is a region, the FREEMAIN routine issues a FREEPART 
macro. Upon completion, control returns to the 
calling routine [IBM 19724 ]. 


FREFPART: The FREEPART routine is entered from the FREEMAIN 
routine. Its first function is to use the Task 
Ccntrol Block representing the task to locate the 
partition queue element of the appropriate region. A 
FREEMAIN is then issued to release the space in the 
Supervisor Queue Area occupied by the fartition queue 
element. Next, if the region to be freed 1S adjacent 
to an existing free area, it is combined with that 
area. If not, an element representing the region is 
added to the chain of free areas. Finally, if there 
is an initiator waiting for a region it is notified 
and control returns to FREEMAIN [IBM 1972d]. 


GETMAIN: The GETMAIN macro is used for all requests for 
space in main storage. These include requests for 
regions, space within regions, and space within the 


Supervisor Queue Area. The GETMAIN routine scans 
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queues of elements that represent available space to 
locate the amount of space of the type requested. 
When the space is -fcund, the affected queues are 
updated indicating that the space is no longer 
available and the address of the space is returned to 
the requester. If the request is for a region the 


GETMAIN routine issues the GETPART macro [IBM 1972d ]. 


GEIFART: The GETPART routine is entered via the GETMAIN 
routine. It first determines whether there is enough 
Space in the Supervisor Queue Area to initiate the job 
step and whether there is enough free space in the 
dynamic area to fulfull the request. If there is not 
enough space avallable, the initiator is put into a 
wait state and control passes to the highest priority 
ready task in the system. If the requested space is 
available, the GETPART routine issues a GETMAIN to 
obtain space in the Supervisor Queue Area for the 
partition queue element. The GETPART routine then 
adjusts the pcinter in the partition queue element to 
point to the newly acquired region and returns ccntrol 
to GETMAIN [IBM 19724 ]. 
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APPENDIX C 


This appendix presents a detailed description cf job 
initiaticn under 05/360. Readers unfamiliar with CS/360 
should refer to Appendix À and Appendix B for explanations 


Of IBM terms and system macro instructions. 


The initiator is composed of many modules, each with a 
specific function. Some of these modules are permanently 
core resident in the Link Pack Area, others are broucht into 
core only as they are needed. The flow of control depends 
upon the characteristics of the job being initiated and upon 


the availability of the resources requested. 


The discussion below follows the flow of control through 
the initiator modules during the initiation of a typical 
jot. Coverage is limited to resource allocation and is not 
concerned with other housekeeping functicns which dc not 


affect deadicck prevention. 
A. JOB SELECTION 


The Job Selection routine must first determine if there 
is a jcb in the input queue which can be initiated by this 
initiator. To do this it issues an ENQ macro on the queue 
control record to obtain exclusive control cf it. When the 
queue control record becomes available it is read into core 
and examined. If there is no job in the input queue a DEC 
macro is issued, freeing the queue ccntrcl reccrd. A 
message is then sent to the console informing the operator 
that the initiator is waiting for work. Control passes to 
the Initiator Wait routine resident in the Link Fack Area 


which frees the core held by the initiator. When a jcb is 
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placed in the input queue the Initiatcr Wait routine is 
notified. It then obtains a new region of main storage and 


Ba ses control to the Job Selection routine. 


If there are jobs in the input queue, the highest 
pricrity jok is selected. The queue control record is 
updated to indicate the selection and is written back into 
the queue. Then a DEQ macro is issued permitting access to 


the queue control record by other routines. 


The jcb ccntrol table describing the selected job is 
read intc ccre. From it is extracted the number of steps in 
the job and the location of the step contrcl table fcr each 
ster. The step control table for the first job step to be 


MM ttated is now read into core. 


The dispatching priority of the initiator is changed to 
the pricrity specified TOU the job. Reducing the 
initiatcr's priority forces its contemticn for systen 
resources (e.g. the CPU) to be at a priority equal to that 


of the job being initiated. 


Next the Job Selection routine reads intc core the table 
containing the name and disposition of all non-temporary 
data sets required by the entire job. With this infcrmation 
it kuilds a parameter list for the ENQ macro specifying each 
data set name and whether its use is exclusive or shareable. 
When the farameter list is completed it is written into the 
Supervisor Queue Space and control is passed tc the 


Determine Regicn Size routine. 
B. REGION MANAGEMENT 
The modules of the initiator operate in various regions 


of main storage. When the initiator is first entered it 


operates in a regicn obtained for it by the Systen Task 
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Control routine. After that, main storage is obtained and 


released ty the initiator modules in the Link Pack Area. 


The Letermine Region Size routine compares the region 
size requested by the job with the minimum region size 
reguired to initiate a job step. It determines the step 
region size as the greater of the two. It then stores this 
region size, along with other information not pertinent to 
this discussicn, into a work table and writes it into the 
Supervisor Çueue Space. The location of the work table is 


passed tc the Get/Free Region routine. 


The GetyFree Region routine resides in the Link Pack 
Area. When it is entered, it frees the old region used by 
the initiatcr and issues the ENQ macro for data sets using 
the parameter list created by the Job Selection routine. If 
the routine is unable to obtain all of the data sets 
Specified, it issues a DEQ to free those obtained. It then 
sends a message to the console notifying the operator ci the 
data sets not available. The operator iS given the option 
of retrying the ENQ, cancelling the job, or waiting fcr the 


data sets to become available. 


When the ENQ is coumpleted, the storage occupied ty the 
parameter list is freed. The GETPART macro is then issued 
to ottain the regien specified in the work table. When it 
has obtained the region of main storage, control is passed 
to the Allocation Interface routine which is loaded into the 


new regicn. 
Cw I/O DEVICE ALLOCATION 

The Allccation Interface routine releases the core used 
by the work table, does some routine status checking which 


heed not be discussed, and calls the I/O Device Allccation 


routine as a subroutine. The I/O Device Allocation routine 
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is wade up of submodules, therefore numerous module names 


will appear in this Section. 


Since both the I/O Device Allocation and Termination 
routines modify the unit control blocks and may be operating 
concurrently on Seperate system tasks, the unit ccntrol 
block table must be protected from multiple accesses. To 
prevent this the Allocation Entry routine issues an ENQ on 
the table for the I/0 Device Allocation routine. Since the 
ENQ is issued at the beginning of the routine the effect is 
to prevent allocation from being performed for more than one 


jok step at a time. 


When the Housekeeping routine receives control it issues 
an ENO on the unit control blocks in the name cf the 
Tersiraticn routine. This prevents termination of any job 
step while housekeeping is taking place. This routine also 
issues an ENQ on the unit control blocks to prevent 
allccation rcutines for another task from using them during 


this allccaticn processing. 


The Housekeeping routine analyzes the requests for I/O 
devices and stores the information necessary for allccation 
in tabular form for reference by the allocation routines. 
It also references the system catalogue in order. to add 
volume information to existing tables, such as the Step 


Gomtrol Table and the Step Input/Output Table. 


Before the Housekeeping routine passes control to the 
Allocation Control routine, it issues a DEQ tc allow 
Teruinaticn to have access to the unit control blocks while 
Allccation Control is building tables. The tables built at 
this time are numerous; a detailed description of each would 
be impractical and would not contribute to meeting the goals 
of this paper. Most of the tables are not completed at this 
time but are filled by other modules. At this pcint the 


38 





space required for each is determined, main storage is 
allocated, and a control table which points to them is 
built. 


The Lemand Allocation routine is entered frcr the 
Allccaticn Ccntrol routine. It issues an ENG on the unit 
control blocks to prevent access by the Termination rcutine 
and then tegins to build tables. The first table filled in 
1s the allocate work table. The ailocate work table entry 
contains informaticn describing the data set and other 
infcrmation required for device allocation. This 
infcrmaticn is obtained primarily from other tables such as 
the Step Input/Output Table. Using the information now in 
the allocate work table, a search is made of the unit 
control tlccks for all devices which would satisfy the 
requirements of the data set. A bit pattern representing 


these devices is stored in the allocate work table. 


Next the channel load table is filled in. For the 
purpose of allocation, the load on a channel is defined as 
the number cf data sets which are currently accessible 
through that channel. The channel load takle contains an 


entry for each logical channel in the systen. ` 


When the Demand Allocation rcutine has finished building 
tables, it then begins making unit assignments. It first 
makes all’ assignments for resident direct access volumes. 
It then determines which devices are not eligitle for 
allccation and eliminates then fron the range of 
consideration. A device is ineligible if it is off-line, 
contains a resident volume, or has been allocated. The 
device is eliminated from the range of consideraticn by 
setting the bit corresponding to the device to zerc in the 
bit pattern cf the allocate work table entry. The final bit 
pattern represents only devices which can satisfy the 


request. 
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FinaTly, all explicit and implicit requests for specifie 
devices are honored. If there are still outstanding 
requests at this point, control is passed to the Decision 
Allccation routine; otherwise, control is passed to the Task 


Input/Output Table (TIOT) Construction routine. 


The Decision Allocation routine first examines each 
allccation request and determines which units could ke used 
to fulfill them. This decision takes into account requests 
for channel separation between data sets, requests for data 
sets to be on the same device, and that data sets passed 
from pricr job steps are already mounted on specific 
devices, When the range of eligible devices has been 
reduced as much as possible, allocation begins. Data sets 
are selected for allocation beginning with the nost 
restrictive requests. When the data set has been selected, 
devices are considered in the following order: a device on 
the channel with the greatest number of free units, a device 
on the channel with the lightest work load, or the first 
device in the unit control table. The number of free units 
is determined by consulting the unit control blocks and the 
channel work load is obtained from the channel load table. 
When a device is chosen it is eliminated from the list of 
eligible devices for all other data sets and the next data 
set is selected for allocation. When allocations have been 
made for all reguested data sets, control is passed to the 


Peet Construction routine. 


If allocation is impossikle because of lack of devices, 
the operator is given the option of cancelling the job, 
making a device available which is offline, or waiting for 
devices to become available. If the” wait “option is 
selected, the Wait for Unallocation routine is entered. The 
Wait for Unallocation routine issues two DEQ'S which ailow 


access to the unit control blocks by the Termination routine 
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and by aliccation routines for other tasks. These two DEO!s 
correspond to the two ENQ'S issued in the Housekeeping 
routine. When a task terminates, freeing its I/O devices, 
control returns to the Wait for Unallocaticn routine which 
issues twc ENQ's on the unit control blocks. Allocation is 


then attempted again. 


The TIOT Construction routine builds the task 
input/output table. The task input/output table is used to 
provide information to I/O support routines such as OPEN, 
CLOSE, and EOV. The table contains an entry for each data 
set requested for the job step. The TIOT Construction 
routine also allocates direct access storage space on public 


volumes. 


The External Action routine issues mounting instructions 
to the operator for all volumes required. If an incorrect 
volume is mounted the operator is again issued a mount 
message ccntaining the correct volume identification. After 
all volumes have been verified control is passed to the 


Allłlccaticn Exit routine. 


The Allccaticn Exit routine is entered after all 
allccaticns have been successfully made or if an error 
condition has been detected. If the routine is entered 
because of an error condition it sets a bit indicating that 
the job step should be flushed. If the routine is eatered 
after allccation it writes the aliocation messages into the 
output queue. In either case, it issues two DEQ's to allow 
access to the unit control blocks by allocation and 
terminaticn routines performing other tasks and returns 


control tc the Allocation Interface routine. 
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ME ATTACHING TASKS 


By the tine the initiation process has reached this 
stage all of the allocations have been completed. What 
remains is gathering the information needed by the 
supervisor to run the task. This infornation is passed via 
the ATTACH macro. | 


Upon the completion of device allocation, control 
returns to the Aliocation Interface routine. It tests the 
condition of the allocation to determine whether or not it 
was successful; if so, it proceeds. The Table Breakup 
routine is used to convert the task input/output table into 
a series of records which are added to the task's input 
queue entry. Next the job control table and the step 


control table are written back into the work queue data set. 


The Allocation Interface routine now builds the 
parameter list for the ATTACH macro. It also builds the 
initiator parameter list which contains pointers to the 
ATTACH parameter list and other pertinent lists and tables. 
Control is now passed to the Pre-Attach routine. 

The Pre-Attach routine determines the priority at which 
the job step «ill be attached and passes control to the 
Attach routine which issues the ATTACH macro. When ATTACH 


has been issued, execution of the job step begins. 
E. TASK TERMINATION 


A task is terminated when it reaches ncrmal conpletion, 
abncrmally ends execution, exceeds its requested tine 
interval, exceeds its output limit, or is cancelled Ly the 
Operator. When any of the above conditions is enccuntered, 
control is given to the Termination routine which functions 


as a Subroutine of the initiator. The Termination rcutine 
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is a collection of modules performing terniration 


housekeeping, step termination, and job termination. 


The first module encountered is the Termination Entry 
routine. It places termination messages into the cutput 
queue and if the program ended abnormally it passes control 
to the Indicative Dump routine. The Indicative Dump rcutine 
Writes a message to the progranner indicating the user and 
system completion codes and passes control to the Step 


Terfinaticn Ccntrol routine. 


The Step Termination Control routine determines whether 
the step was normally terminated. If not, certain actions 
are required. In this discussion a normal termination is 
assummed and control is passed to the Data Set Driver 


routine. 


The Lata Set Driver routine reads a step input/output 
table entry tor the step into main storage. It then passes 
control tc the Disposition and Unallocation routine which 
processes the data set specified by the entry. Ccntrol 
returns tc the Data Set Driver which brings in the next step 
input/output table entry. This loop continues until all 
entries for the step have been processed; control then 


returns to the Step Termination Control routine. 


The Lispcsition and Unallocation routine first performs 
data set disposition as specified in the data definition 
statenent. This includes updating the system catalogue to 
reflect an addition or deletion of a data set, scratching 
Space on direct access volumes, and/or passing data sets to 
subsequent job steps. Next an ENG macro is issued on the 
unit control blocks and the I/O device corresponding to the 
data set is unallocated. If the data set can be demounted 
from the device, a message is sent to the console irforming 


the operator. When unallocation is complete a DEQ is issued 
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freeing the unit ccntrol blccks and control returns to the 


Step Termination Control routine. 


If the jcb step just terminated is not the last step in 
the job, ccntrol passes to the Step Termination Exit routine 
Which returns control to the calling routine. In this case 
the calling routine is the initiator which then HEegins 
processing the next job step. If the job step just 
terminated was the last step in the job the Job Termination 


@entrcl rcutine is entered. 


The Job Termination Control routine examines the job 
control table to determine if any data sets have been passed 
or retained which were not referenced by a subsequent step. 


If there are, the Disposition and Unallocation routine is 


used to process then. When all data sets have been 
processed control passes to the Job Termination Exit 
routine. 

The Job Termination Exit routine places the last 


ternrinaticn ressage into the output queue, completes the 
output gueue entries, and issues a job ended message to the 
operator. The initiator is now free to process another job 


and the entire initiation process begins again. 
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APPENDIX D 


The entries in this appendix describe MTS elements used 


in communications between the supervisor and the Paging Drum 


Processor. The source of information for all five entries 
is [Alexander 1971]. 


Page 


Page 


Page 


Contrcl Block: There is a page control block for every 
virtual memory page in the system. The page ccntrol 
block is always on a linked list of pages owned by the 
task and may also be on one of the four system queues 
listed below. It contains the status of the page. The 
fields of the page control block are: the address of 
the next PCB for the same task, the main storage 
address of the page, the virtual memory address of the 
page, the status of the PCB, the address of the PCB on 
the system queue, the number of pages in the same 
block, the address of the Task Control Tabie for the 
task owning the page, the number of lock requests for 
the page, a scratch area to be used by thé supervisor, 
the stcrage key, the status of the page, and the 


auxiliary storage address of the page. 


In Cueue: This is a queue of all PCB's for pages which 
have been requested by the supervisor, but which the 


Paging Drum Processor has not yet started to read in. 


In Complete Queue: This is a queue of all PCB'S for 
pages which have been read in by the Paging Drum 
Processor, but of which the supervisor is fret yet 


aware. 
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Page Out Çueue: This is a queue of all PCB's for pages in 
main stcrage which can be paged out if more space is 
required. The PCB's are arranged in order of 


desirability of removal. 
Release Page Queue: This is a queue of PCB's for all pages 


which have been released by their tasks, but which have 


not yet been released by the Paging Drum Processor. 
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APPENDIX E 


| entries in this appendix describe superviscr calls 
y the Paging Drum Processor. The SOUICE of 


ition for all five entries is [Alexander 1971]. 


lues: This supervisor call is useđ by the Paging Drum 


'OÒCESSCr to get the Page In Queue and the Release Page 


Jeue. 
he Fage: This supervisor call is used by the Faging 
Jum Prccessor to request a main storage block. PES 


.OCk is available it is allocated to the page and the 
Idress is returned in the page control block. If no 


MWEk can be aliocated a condition code so indicates. 
f 


bte Page: This supervisor call is used py the Paging 
pun Processor to request the number of pages required 
» fill the empty slots on the paging drum fcr the 
evolution being scheduled. The supervisor will return 
o to the number of pages requested, depending cn their 


Be: and how full memory is. 


sal Page: This supervisor call is used by the Faging 
rüm Processor to inform the supervisor that a blcck of 
ain stcrage is now available for reallocation. It is 
MO used by the supervisor to notify the PDP that the 
age was reclaimed by its task while it was being 
ritten out to the drum. In this case the PDF marks 


he copy of the page on auxiliary storage as invalid. 


30: This supervisor call is used ky the Paging Drum 


ICcesscr to inform the supervisor that it has no more 
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work tc do. Therefore the next time the EDE is 
required it will have to be restarted by the 
supervisor. 
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